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(54) Distributed processing architecture for control of broadband and narrowband communications 
networks. 

(57) A distributed, server-based communications 
network architecture delivers broadband and 
narrowband communications services. In the 
architecture, various traditional call processing 
functions, such as switching fabric or channel 
control, call control, and connection control are 
separated into distinct application processes 
with clearly defined interfaces for communi- 
cations between these application processes. 
Those distinct application processes may be 
implemented in separate physical or logically 
partitioned nodes. The well-defined interfaces 
allow communications among : a) physical or 
logically partitioned nodes within a network and 
b) physical or logically partitioned nodes of 
other networks. 
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This invention relates to communication systems. 
More specifically, this invention relates to communi- 
cations systems supporting broadband and narrow- 
band voice, data and video communication services. 

Background 

Over the years, advances in communications 
networks architecture have allowed new telecommu- 
nications services to be offered by communications 
carriers. For example, the introduction of a separate 
signaling subnetwork within a communications net- 
work paved the way for the introduction of services, 
such as software-defined network and freephone 
services. Likewise, communications arehitectures 
have changed in response to needs of the market- 
place for particular telecommunications services. For 
example, persistent requests for customized services 
from subscribers were the driving force behind the 
creation of a service-independent capabilities-based 
architecture called "Intelligent Network" (IN) architec- 
ture. The IN architecture represents an evolutionary 
step from the traditional communications architec- 
ture. More specifically, changes were introduced in 
the traditional architecture to meet the requirements 
of the IN-based services. Of particular importance in 
the IN-architecture is the separation of the service 
control functions from the transport control func- 
tions. However, one of the drawbacks of the IN archi- 
tecture is that all network nodes must be capable of, 
and may be required to perform, loosely coupled 
functions aimed at different objectives i.e., there is a 
bundling of distinct control functions, such as call 
control, connection control and channel control. As a 
result, introduction of new services associated with 
one of these functions require changes to software 
that effects all of these functions and that is loaded 
in these network nodes. 

With the impending standardization of Broad- 
band Integrated Services Digital Network (B-ISDN), 
an emerging class of new services is anticipated to be 
offered by carriers and third party vendors. Those 
services incluue high bandwidth multimedia, multi- 
point applicators ; .nt*»ractive video services, bulk 
data retrieval and archiving, messaging and distribu- 
tional services. Associated with these new services 
are switching, connection, and signaling require- 
ments whose complexities are unparalleled in today's 
communications networks. Requirements that have 
been identified include user/server negotiation re- 
quirements, dynamic modification of active connec- 
tions, recognition of need for special resources (such 
as protocol converters and bridges), to name a few. 

From the foregoing, it is clear that today's com- 
munications network architectures are ill-suited for 
those emerging requirements. Thus, a new commu- 



nications architectures needed to allow communica- 
tions networks to support the emerging B-ISDN ser- 
vices while at the same time accommodating tradi- 
tional and IN-based telephony services. Unlike the 

5 evolutionary adaptation of the traditional communica- 
tions architecture to meet the requirements of IN-ba- 
sed services, the complexity of call and connection 
controls in a B-ISDN environment requires a para- 
digm shift in communications network architectures 

10 to meet the performance-demanding requirements of 
B-ISDN services. 

Summary 

15 The present invention is directed to a distributed, 

server-based communications network architecture 
in which various traditional call processing functions, 
such as switching fabric or channel control, call con- 
trol, connection control are separated into distinct ap- 

20 plication processes with clearly defined interfaces for 
communications between these application process- 
es. Those distinct application processes may be im- 
plemented in separate physical or logically parti- 
tioned nodes. The well-defined interfaces allow com- 

25 munications among physical or logically partitioned 
nodes within a network, physical or logically parti- 
tioned nodes of compatible networks, and customer 
premises equipment connected to a compatible net- 
work. 

30 In a preferred embodiment of the invention, ob- 
ject-oriented analytical tools are used to derive four 
types of models to identify the functions associated 
with call processing in a B-ISDN, N-ISDN and tradi- 
tional communications networks. These models are: 

35 an Information Model (IM), State Models (SM), an Ob- 
ject Communications Model (OCM), and Process 
Models (PM). An Information Model (IM) is similar to 
an "Entity-Relationship" diagram in which, all data as- 
sociated with a physical or logical entity are grouped 

40 into "objects". Included in the data for physical ob- 
jects, such as CPE (also called "users"), switches, 
and adjunct processors (also called "servers"), are 
the respective attributes of these objects, such as, 
identifiers and object-specific parameters. For inter- 

45 communications between the physical objects, the 
model also identifies communications objects, such 
as call, connection and channel, with their respective 
attributes and relationships to the physical objects 
and other communications objects (one-to-many, 

so many-to-many). 

In the State Models (SM), different states of an 
object instance are defined. When an object instance 
enters a state (the call object in the "call being set up" 
state, for example), it performs certain actions (digit 

55 translation in a server, for example). In the course of 
performing those actions, the object generates 
events that may impact its own state model and 
cause state transitions in other object instances, 



called "cross-object events". The crosRbject events 
for all objects in the IM are identified in the Object 
Communication Model (OCM). The details of data 
flow in an Action Process are provided in the Process 
Models (PMs). 5 

Based on the four models, a multiserver-based 
communications network architecture is derived. The 
architecture is characterized by a functional separa- 
tion of the operations to be performed by the servers. 
For example, existing call processing functions may 10 
be allocated to individual servers as follows: fabric 
control functionality in one or more channel servers, 
connection control functions in one or more connec- 
tion servers, feature management capabilities in one 
or more call servers and service control functions in 15 
service-specific servers, each one of these service- 
specific servers being associated with a particular 
type of communications service. Assignment of par- 
ticular tasks or operations to a particular server re- 
flects the close relationship between objects related 20 
to particular sub-functions, as indicated by the num- 
ber of cross-object events associated with those 
tasks or operations. For example, the call- 
connection-mapping, the route and the connection 
objects are managed in one server. Details of a suite 25 
of protocols defined to enable communications be- 
tween these application processes are provided in 
the commonly assigned co-pending United States pa- 
tent application, Serial No. 08/082,654 entitled "Com- 
munications Signaling Protocols". 30 

' Br * ef Description of the Drawing 

FIG. 1 is a table that lists objects and their asso- 
ciated attributes for B- ISDN communications; 35 
FIG. 2 depicts instances of the call, channel, con- 
nection and route objects for an illustrative mul- 
tipoint, multiconnection call in a B-ISDN network- 
ing environment; 

FIG. 3 shows some of the objects of FIG. 2 and 40 
the number of cross-object events needed be- 
tween these objects to perform certain traditional 
call processing functions in a broadband commu- 
nications network to establish communications 
between users; 45 
FIG. 4 shows an illustrative arrangement of ser- 
vers in which multiple objects are grouped to- 
gether in certain servers to limit the number of 
signaling communications messages. 
FIG. 5 shows a block diagram of a distributed so 
processing architecture for a broadband and nar- 
rowband communications network; and 
FIG. 6 is an illustrative block diagram of a multiple 
network configuration for the distributed archi- 
tecture of FIG. 5. 55 



Detailed Description 




FIG. 1 is a table that lists objects and their asso- 
ciated attributes for B- ISDN communications. The ta- 
ble of FIG. 1 is derived from the use of an analytical 
tool known in the art as "Object Oriented Analysis" 
(OOA). OOA advocates the building of four types of 
models: Information Model (IM), State Models (SM), 
Object Communication Model (OCM), and Process 
Models (PM), to ascertain the characteristics of enti- 
ties and the relationship between those entities that 
are called "objects". An object identifies all the data 
associated with the application domain of each entity 
being analyzed. In an SM (one per object identified in 
the IM), different states of an object instance are 
shown. When an object instance enters a state, it per- 
forms certain Actions. As part of these actions, it gen- 
erates Events. Events generated in the state model 
of an object may cause state transitions in another ob- 
ject or cause transitions in its own state model. Data 
may be associated with an event. The OCM shows 
only those events generated in an object that cause 
transitions in another object's state model. An Events 
dictionary lists all the events in the different state 
models. A PM is used to provide details of data flow 
with an Action Process (combined list of actions) in 
each State of each Object. 

FIG. 1 is a representation of a part of an Informa- 
tion Model (IM) for a broadband network. In FIG. 1, an 
exemplary list of identified objects is provided in the 
first column on the left hand side. Relationships be- 
tween objects can be one-to-one, one-to-many, or 
many-to-many. Associative objects and relational at- 
tributes are used to represent many-to-many relation- 
ships. In FIG. 1 , the callconnection-mapping, the VCI- 
Translation-Table-entry and the user-call-interaction 
are associative objects. 

In the middle column of the table of FIG. 1 are list- 
ed the identifying attributes of the objects. All of 
these attributes are either self-explanatory or are de- 
scribed in further detail below. 

Listed in the first column on the right hand side 
are the non-identifying attributes of the objects. 
Those attributes identify particular characteristics 
associated with an object. For example, non-identify- 
ing attributes of a call object include Server Identifi- 
ers and User Identifiers to particularly point-out the 
servers and users involved in the call. Similarly, non- 
identifying attributes of a switch include Capacity of 
the Switch, Number of Priorities Offered, Maximum 
Switching Rates. 

FIG. 2 depicts the instances of the call, channel, 
connection and route objects for an illustrative multi- 
point, multiconnection call in a B-ISDN simplified net- 
working environment. Trie objects shown in FIG. 2 are 
a) the users 201 , 209 and 21 0; b) the connections 202 
and 203; c) the switches 207 and 208; d) the server 
211, the route 212, the channels 204, 205, 206 and 
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the call 214. The characteristics, ^^Hputes, and the 

operations and functions associatecroith each object 
are discussed below. 

In FIG. 2, a user 201 is shown connected to a 
switch 207 via a channel 204. The user 201 may be, 
for example, a digital Communications Premises 
Equipment (CPE), such as a PBX, a data terminal or 
data communications equipment, arranged to trans- 
mit and receive data at fixed or variable rate. Connec- 
tions 202 and 203 represent communications paths 
between users 201, 209 and 210 through switches 
207 and 208. In B-ISDN terminology, a connection, 
such as connection 202 or 203 is called a "Virtual 
Channel Connection" (VCC). Although connections 
202 and 203 are shown as multipoint communications 
paths terminated on users 209 and 210, connections 
may be configured as point-to-point communications 
paths terminated on users as well as servers. An im- 
portant characteristic of connections 202 and 203 is 
that they extend between points (such as, users 201 , 
209 and 210) where the ATM adaptation layer proto- 
col (AAL) which manages end-to-end communica- 
tions, is terminated. Connections 202 and 203 are in 
effect, a "slice" of the route 212, utilizing a portion of 
the resources of that route over which they run. For 
communications in the broadband network of FIG. 2, 
connections 202 and 203 are referenced by a) their 
unique connection identifier called a Virtual Channel 
Connection Identifier (VCCI) and b) the end entity 
identifiers (users or servers). Of particular impor- 
tance are the attributes of connections 202 and 203. 
These attributes include performance metrics, adap- 
tation layer parameters, directionality, symmetry and 
the identifiers of switches in these connections. 

Functions associated with the control of connec- 
tions 202 and 203 comprise a) connection establish- 
ment including end-to-end Quality-of-Service (QOS) 
computation, b) connection release, c) connection 
modification, and d) connection status and configur- 
ation information management. In the broadband net- 
working environment of FIG. 2, since a single connec- 
tion may be active on many calls, or a single call (such 
as call 214) may have many active connections (such 
as, connections 202 and 203), the relationship be- 
tween the objects are many-many. For this reason, 
an associative object called the call-connection map- 
ping is defined to map connections into calls. 

Included among the physical objects of FIG. 2 are 
switches 207 and 208. Those switches are preferably 
Asynchronous Transfer Mode (ATM) switches that are 
arranged to format, multiplex, cross-connect and 
switch information in 53-byte packets called "cells" to 
support voice, data and video services (in an integrat- 
ed fashion or individually) at a wide variety of inter- 
face speeds. Because of the variety of services sup- 
ported by a broadband network in general and 
switches 207 and 208, in particular, a call, such as call 
214 needs to be controlled. Call control functions in- 



clude a) service cooranation to identify service re- 
quests and reconcile conflicts (when present) among 
those services, b) end-to-end negotiation to match 
(for the call) requested services and resources to 

5 available services and resources in the network, c) 
management of information regarding status, config- 
uration, ownership and permissions information for 
calls, d) interaction with connection servers e) user- 
to-user, user-to-server negotiations and f) the estab- 

10 tishment and release of calls. 

Also shown in FIG. 2 is a route 212 which consists 
of a network communications path that connects 
users 201, 209, 210 through switches 207 and 208. 
Although in FIG. 2, route 212 is depicted as a multi- 

15 point path, it would be appreciated that a route may 
be point-to-point or multipoint. Associated with route 
212 are particular attributes, such as performance 
metrics, bandwidth, directionality, symmetry and 
identifiers of switches in the route. Route control 

20 deals primarily with the availability of routes and re- 
sources on each route. 

In FIG. 2, a channel 204 is a logical link between 
the user 201 and the switch 207. Similarly, the chan- 
nel 205 connects ATM switches 207 and 208, while 

25 the channels 206 and 214 provide links between ATM 
switch 208 and users 209 and 210, respectively. In 
the broadband networking environment of FIG. 2, a 
channel is referenced by the Virtual Path Connection 
Identifier (VPCI), and end entity identifiers and port 

30 numbers. Associated with channels 204, 205, 206 
and 213 are ATM layer and performance attributes. 
Functions related to channel control include a) man- 
agement of resources such as, VPCIs and VCIs, on 
a link by link basis, and b) entries and updates of VCI 

35 translation table data that are needed to interconnect 
channels that are part of a connection. 

FIG. 3 shows some of the objects of FIG. 2 and 
the number of cross-object events needed between 
these objects to perform certain traditional call proc- 

40 essing functions in a broadband communications net- 
work to establish communications between users. 
The objects in FIG. 3 communicate in a manner that 
is consistent with the OCM. In FIG. 3, a labeling 
scheme has Deen adopted to identify the number of 

45 transactions and cross-object events required for 
communications between users and servers. The 
digit in parentheses indicates the number of cross- 
object events needed to carry out communication be- 
tween two objects, while the digit to the left of the one 

so in parentheses points out the number of transactions 
needed for the same communication. For example, 
one transaction and two cross-object events are 
needed for communications between the user object 
301 and the call server object 302. As shown in FIG. 

55 3, a similar numuer uf transactions is needed for com- 
munications between the call object 302 and the ser- 
ver object 303. 

Because of the potential high number of routes, 
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connections and channels that may beneeded to set 
up and maintain a call in a broadband communica- 
tions network, the number of transactions and events 
between objects needed for that call may be signifi- 
cant. For example, the number of transactions and 
cross-object events needed for communications be- 
tween the route object and the call-connection- 
mapping object is a function of n, where n represents 
the number of routes active in the call. Similarly, the 
number of transactions and cross-object events 
needed for communications between the route object 
and the call-connection-mapping object is a function 
of m, where m represents the number of connections. 
Likewise, communications between the connection 
object and the channel objects require p transactions 
and 2p cross-object events, where p represents the 
number of channels. 

FIG. 4 shows an illustrative arrangement of ser- 
vers in which multiple objects are grouped together in 
certain servers to limit the the number of signaling 
communications messages. FIG. 4 shows a client 
represented by user 401 connected to a call server 
402. The latter is also connected to a communications 
services server 403 and to a connection server 404 
which is itself linked to a channel server 405. FIG. 4 
is derived from the IM and OCM models of the Object- 
Oriented Analysis methodology. More specifically, 
objects that use a significant number of transactions 
and cross-object events to perform an operation as- 
sociated with a call processing function, are simply 
placed in the same server. For example, the connec- 
tion server 404 manages the call-connection- 
mapping object 304, the connection object 306 and 
the route object 305 of FIG. 3. Similarly, the channel 
server 405 manages the channel object 307 and the 
VPI/VCI object 308 of FIG. 3. By grouping these ob- 
jects in the same server, the number of transactions 
and signaling messages needed for communications 
between the servers is greatly reduced. For example, 
only one transaction and two signaling messages are 
needed for communications between the servers of 
FIG. 4 or between the user/client 401 and the call ser- 
ver 402. 

FIG. 5 shows a representation of a distributed 
processing architecture for a broadband and narrow- 
band communications network. The distributed proc- 
essing architecture of FIG. 5 is based on the cli- 
ent/server distribution structure of FIG. 4. In FIG. 5, 
user/clients and their instances are represented by 
CPE 501, 513 and 514. The servers in the distributed 
architecture of FIG. 5 include channel servers 506 
and 511, connection server 504, call server 502 and 
service-specific servers 519, 521, 523 and 525, 
which are representative of the types of communica- 
tions services that can be provided in a broadband 
communications network. It is to be understood that 
other types of service-specific servers could also be 
included in the distributed architecture. Connected to 



the call server 502 ar^Bisers database 516 and a 
service database 517, wnich store subscriber profile 
and service-specific information that may be shared 
by the service-specific servers. Also shown in FIG. 5 
5 are Switching Offices (SO) 508 and 510. The latter 
are Asynchronous Transfer Mode (ATM) switches ar- 
ranged to cross-connect, switch and multiplex inte- 
grated, voice, data and video traffic. 

In FIG. 5, each server executes an application 
10 process or call processing subf unction that is shown 
within an ellipse in that server. For example, since the 
call object is placed in the call server 502, it follows 
that the associated call control application process 
503 should be located in the same server. Each ser- 
fs ver in the architecture is designed to operate in a 
modularfashion, i. e., independently of the operations 
of the other servers. The call server 502 has knowl- 
edge of the operations of the service-specific servers 
518, 520, 522 and 524 and connection server 504 
20 only to the extent necessary for communications with 
those servers and to to manage feature interaction 
within a call. The servers of FIG. 5 are shown as phys- 
ically separated from each other. It would be appreci- 
ated that those servers can be logically partitioned 
25 without being physically separated from one another. 
Channel servers 507 and 512 are associated with 
switches 508 and 510. Those servers maintain all in- 
stances of the channel object associated with the 
ports of their associated switch. They also maintain 
30 instances of the VCI Translation Table Entry object for 
connections that traverse the switch (508 or 5 1 0) with 
which the particular channel object (506 or 512) is as- 
sociated. 

The connection sei 5u * provides bearer ser- 

35 vices with capabilities to add, drop or modify a con- 
nection through switches 504 and 510. In addition, 
the connection server 504 provides common/diverse 
routing of connections and end-to-end Quality-of- 
Service (QOS) computation for connections. Con- 

40 nection servers 504 also maintain connection, state 
and configuration information. 

At the heart of the distributed architecture of FIG. 
5 is call server 502, which is arranged to provide the 
functions such as: facilitate user-to-user and user-to- 

45 network negotiation of options and check for 
user/server status and compatibility; provide service 
invocation and coordination functions; recognize any 
need for special resources (e.g. converters); maintain 
call state, configuration information; and manage call 

so reference values and user account information; inter- 
act with connection servers; and establish, modify 
and release calls. To provide these functions, call ser- 
ver 502 is physically linked to the CPE 501, 513 and 
514 and the service-specific servers 519, 521, 523 

55 and 525. In addition, call server 502 has also a phys- 
ical link to connection server 504 for connection and 
route control functions. 

To illustrate how call processing functions are 



performed for the establishment q^Kwo-party call, 
let us take the example of a user wWinitiates such a 
call and desires certain services with certain attri- 
butes to be provided in that call. The request message 
and the underlying parameters for the desired servic- 5 
es associated with that call are sent by the user as a 
service invocation to the call server 502. The latter 
processes the request and forwards the associated 
parameters to the appropriate service-specific ser- 
vers to invoke operations as necessary in those ser- 10 
vice-specific servers. The latter servers may interact 
with like servers (even in other networks) to perform 
the operations indicated by the call server 502- At the 
completion of these operations, the service-specific 
servers report the results of their operation(s) to the 15 
call server 502. The latter performs user-to-user and 
user-to-server negotiations based on the results of 
the operations performed by the service-specific ser- 
vers. Subsequently, the call server 502 invokes the 
services of connection server 504 to request that con- 20 
nections with certain performance and routing char- 
acteristics be established. As part of its route control 
functions, connection server 504 may retrieve rele- 
vant information from other connection servers or 
may query channel servers 506 and 511 for appropri- 25 
ate information. When the connection server 504 has 
selected the routes for the connections, it invokes the 
services of the channel servers 506 and 511 to estab- 
lish the virtual channel links. At the end of their oper- 
ations, the channel servers 506 and 511 report the re- 30 
suit of these operations. If the channel operations 
were successful and the requested channels have 
been allocated, the connection server 504 returns a 
positive result message to the call server 502 indicat- 
ing that the requested connections have been estab- 35 
lished. At that time, the call server 502 returns a pos- 
itive result message to the users involved in the call 
indicating that the call has been established. 

While the operations indicated in the example 
above are described sequentially for clarity purposes, 40 
it would be appreciated by persons skilled in the art 
that some of these operations may be performed con- 
currently with other operations. 

FIG. 6 is a block diagram of a multiple network 
configuration for the distributed architecture of FIG. 45 
5. Shown in FIG. 6 are four networks 600, 610, 620 
and 630 designed in accordance with the client/ser- 
ver distributed architecture depicted in FIG. 5. Each 
of these networks comprises a call server (6007 for 
Network I, 6107 for Network II, 6207 for Network III so 
and 6307 for Network IV) that is connected to the 
other servers in each network. As described above, 
one of the functions of these call servers is to forward 
parameters associated with a requested service to 
the appropriate service-specific servers and to re- 55 
quest establishment o* connections and channels 
from their respective attached connections servers. 

Also connected to call servers 6007, 6107, 6207 



and 6307 are Signaffrransfer Points (STP) 6008, 
6108, 6208 and 6308, respectively. Those STPs agt 
as gateways for signaling communications messages 
to be exchanged among the networks 600, 610, 620 
and 630. Thus, when one of these networks wants to 
request a particular service from another network as 
part of the call setup process, service request signal- 
ing messages are forwarded from the call server of 
the requesting network (via the requesting network 
STP) to the call server of the destination network (via 
its STP). The call server of the destination network in- 
vokes the requested service from the appropriate the 
service-specific server in that network. For example, 
in a video on-demand application, if user A wants to 
watch a particular movie that is not available on TV 
server 6005, call server 6007, upon being so notified, 
would launch a query that is transmitted via STPs 
6108 and 6308 to call server 6307 to inauire as to the 
availability of that movie in TV server 6305. If the 
movie is available in TV server 6305, user-server ne- 
gotiation is managed by call servers 6007 and 6307. 
Similarly, a call between user A associated with net- 
work 600, and user E associated with network 630 re- 
quires exchange of signaling messages via STPs 
6008, 6108 and 6308 for a) service invocation, b) ser- 
vice coordination between these networks, and c) 
user-user and user-server negotiations. 



Claims 

1; A communications network for delivery of broad- 
band and narrowband communications services 
comprising: 

a plurality of communications servers, 
each one of which is arranged for performing in 
a modular fashion no more than one of the func- 
tions selected from a group which includes chan- 
nel control, call control, and connection control; 
and 

communications means between at least 
two of the servers to exchange signaling mes- 
sages. 

2. The invention of claim 1 further including: 

at least one service-specific server which 
is arranged for a) providing a particular commu- 
nications service and b) performing a service 
control function when said communications ser- 
vice is requested by a user and, c) exchanging in- 
formation between at least one communications 
server in the network and the at least one ser- 
vice-specific server via at least one interface. 

3. The invention of claim 1 further including: 

information databases storing profiles of 
users and subscribers of the communications 
network. 
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4. The invention of claim 1 wherein said communi- 
. cation server performing said call control func- 
tion further includes 

means for invoking services and coordin- 
ating delivery of said invoked services when mul- 
tiple services are requested in a call; 

means for negotiating allocation of re- 
sources between two or more users and between 
at least one user and at least one server; 

means responsive to users' requests for 
recognizing needs for special resources which in- 
clude protocol converters and multimedia 
bridges; 

means for maintaining call state and con- 
figuration information; and 

means for managing ownership and per- 
missions for said call. 

5. The invention of claim 1 wherein said server per- 
forming said channel control function includes 

means for allocating resources on a link by 
link basis to implement a connection; and 

means for maintaining Virtual Channel 
Identifier translation table entries to interconnect 
channels that are part of a connection. 

6. The invention of claim 1 wherein said server per- 
forming said connection control function com- 
prises 

means for establishing, releasing, and 
modifying connections within a call, said modify- 
ing means including means for computing end-to- 
end computation of quality-of-service measures. 

7. The invention of claim 1 further including: 

communications means between at least 
one of the communications servers and another 
server from a different network. 

8. A method of delivering broadband and narrow- 
band communications services comprising the 
steps of 

performing in a modular fashion in each 
one of a plurality o,' c j^ii u ibcions servers no 
more than one of the functions selected from a 
group which includes channel control, call control 
and connection control; and 

exchanging signaling messages via com- 
munications channels between at least two of the 
communication servers. 

9. The method of claim 8 further comprising the 
steps of 

providing a particular communication ser- 
vice in at lead o.:e jervice-specific server 

performing in said service-spsdf ic server 
a service control function when said communica- 
tion service is requested by a user; and 



exchanging^P>rmation between the at 
least one service-specific server and at least one 
communication server in the network via at least 
one interface. 

5 

10. The method of claim 8 wherein the performing of 
said call control function includes the steps of 

invoking particular communication servic- 
es in coordinating delivery of said invoked servic- 
10 es when multiple services are requested in a call; 

negotiating allocation of resources be- 
tween two or more users and between at least 
one user and at least one server, 

in response to particular users' requests, 
15 recognizing needs for special resources which in- 

clude protocol converters and multimedia 
bridges; 

maintaining call state and configuration in- 
formation; and 

20 managing ownership and permission for 

said call. 

11 Tho rrethod of claim 8 wherein the performing of 
said channel control function includes the steps 

25 Of 

allocating resources on a link-by-link basis 
to implement a connection; and 

maintaining virtual channel identifier 
translation table entries which are part of a con- 
30 nection. 

12. The method of claim 8 wherein the performing of 
said connection control includes the steps of 

establishing, releasing, and modifying 
35 connections within a call, said modifying step in- 
cluding end-to-end computation of quality of ser- 
vice measures. 

13. A method of delivering communications services 
40 in a broadband and narrowband communications 

network comprising the steps of: 

receiving in a first communications server 
a user's request for service signals which include 
particular parameters associated with that re- 

45 quest, said parameters comprising origination 

and destination information; 

forwarding to a service-specific server at 
least part of said signals along with instructions 
specifying particular operations to be performed 

so in said service-specific server, 

determining in said first communications 
server resources to be allocated for delivery of 
said service based on the results of the opera- 
tions performed by the service-specific server; 

55 communicating with a) a second commu- 

nications server to request at least one connec- 
tion set up with certain performance and routing 
characteristics, and b) a second communications 



7 



server to request at least one 




il channel link 



set up for delivery of said servRl, said second 
and third communications servers being func- 
tionally separate from said first communications 



receiving in said first communications ser- 
ver messages indicative of the results of the con- 
nection and channel link operations; and 

generating messages signaling said user 
that requested service is available and ready to 10 
be delivered. 



server; 
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